Preserve OCaml namespaces in generated module fields - #1847

Summary

OCaml allows structure components from different namespaces to share a name. For example, an exception constructor and a module can both be named Foo. JavaScript objects have a single property namespace, however, and Melange previously discarded the OCaml namespace while lowering module fields. As a result, the valid OCaml in the reproduction below failed to compile with Foo are exported as twice.

This PR preserves each runtime field's OCaml namespace throughout compiler-libs and the Melange backend. The namespace is then used to give every field an unambiguous JavaScript name:

Values and modules keep their existing names. Extension constructors and classes are also exported under their original names when those names are unambiguous, preserving compatibility for existing JavaScript consumers.

Reproduction

exception Foo of string

module Foo = struct end

Previously, compiling this file failed:

$ melc names.ml
File "names.ml", line 1:
Error: Foo are exported as twice

With this change, both fields are emitted:

$ opam exec -- dune exec -- bin/melc.exe "$(readlink -f names.ml)"
// Generated by Melange
'use strict';

const Caml_exceptions = require("melange.js/caml_exceptions.js");

const Foo = /* @__PURE__ */ Caml_exceptions.create("Names.Foo");

const Foo$1 = {};

module.exports = {
  Foo$extension: Foo,
  Foo: Foo$1,
}
/* No side effect */

OCaml references to the exception use Foo$extension, while references to the module continue to use Foo.

Implementation

• Add a runtime-field descriptor that pairs an identifier with its Shape.Sig_component_kind.t.
• Preserve this descriptor through structure coercions, Lambda module blocks and field accesses, cross-module metadata, and the JavaScript IR.
• Use one namespace-aware naming policy for top-level exports, nested module objects, and imported field accesses.
• Emit the same canonical names in CommonJS and ES module output.
• Keep the original, unmangled name as a compatibility alias when it does not conflict with another field and can be emitted safely.

Tests

The regression test covers:

• exception/module and class/value collisions;
• top-level, nested, local, first-class, and functor-produced modules;
• cross-compilation-unit access;
• signature coercions, include, and open;
• CommonJS and ES module output;
• cross-module optimization; and
• compatibility aliases for non-colliding fields.